Memory devices increasingly contain one or more defective memory blocks. For example, with NOR and NAND flash technology moving to small lithography defects in flash blocks are increasing. In addition to manufacturing related defects, memory blocks can wear out over time and become defective. As a result, defective memory blocks are typically identified and managed so that user data is written or transferred to the remaining good memory blocks of the memory device. Thus, data integrity is maintained despite the presence of one or more defective memory blocks.
Conventionally, the task of managing these defective memory blocks falls onto software, such as a file system software or driver software. However, software implementations usually suffer from a number of problems. For example, software often stores the locations of bad blocks in volatile memory and writes a defect list to a memory block on power off. Thus, if a power loss occurs, the current bad block list may not be saved. In addition, a software implementation adds to the complexity of designing and maintaining the software.
Furthermore, traditionally, the defect list used by a software implementation is often stored in one or more memory blocks when the power is turned off. The defect list can then be read upon subsequent power on of the memory device. However, these memory blocks can also become defective and as result the defect list, or portion thereof, can be lost. Thus, some solutions store multiple copies of the defect list, but multiple copies can increase overhead and reduce the useable amount of memory available. Thus, it is desirable to implement at least some of the defect management in hardware.